[UPDATE] Amazon IVS Low-Latency Streamingでストリームの引き継ぎができるようになりました！ [Stream Takeover]

IVS Low-Latency Streamingで進行中のストリームから別の映像ストリームに引き継ぎができるようになりました。配信されている映像は中断せずシームレスに切り替わります。なんらかの事情でストリームを停止せざるを得ないときに活用できそうです。

#Amazon Interactive Video Service（IVS）

#AWSメディアサービス

#AWS

清水俊也

2024.10.30

はじめに

清水です。AWSのマネージド型ライブストリーミングソリューションであるAmazon Interactive Video Service (Amazon IVS)のLow-Latency Streamingでストリーミングの引き継ぎ（Stream Takeover）ができるようになりました。2024/10/29時点でAWS What's Newへのポストはありませんが、Amazon IVS Low-Latency Streaming User GuideのDocument Historyにて、2024/10/15付けで更新があったことが確認できます。

st01
引用元: IVS Document History | Low-Latency Streaming - Amazon IVS

このStream Takeover機能、詳細についてはUser GuideのAmazon IVS Streaming Configurationのページ、 Stream Takeover の項目にまとめられています。

st02
引用元: Stream Takeover - Amazon IVS Streaming Configuration - Amazon IVS

Channelで進行中のストリームに対して、別の打ち上げ元からのストリームへの引き継ぎ（Takeover）ができるということですね。この際、そのChannelの視聴者には映像自体が途切れることなく、新しくストリームされるものにシームレスに切り替わります。短いバッファリング状態が発生する場合はありますが、視聴者側でプレイヤーを切り替えると行ったことは不要です。またIVSの自動録画機能の管理単位にもなるStream sessionとしても中断されることなく、同じsessionとして扱われます。

なんらかの事情で映像の打ち上げ元（Streaming Software）からIVS Channelへのストリームを停止せざるを得ないときに、代わりとなるStreaming Softwareから映像を打ち上げストリームを引き継がせることで、視聴者への映像配信を途切れずに行い続けることが可能になります。

本エントリでは、このIVS Low-Latency StreamingのStream Takeoverを実際に試してみたのでまとめてみたいと思います。

IVS Low-Latency StreamingでStream Takeoverしてみた

IVS Low-Latency StreamingのStream Takeoverの検証、まずはChannelなどIVS Low-Latency StreamingのリソースをAWSマネジメントコンソールから作成します。続いて、Streaming Softwareの準備と設定を行います。また動画の再生環境として視聴ページについても準備し、実際にStream Takeoverの挙動を確認してみました。

IVS Low-Latancy Streamingのリソース作成

はじめにIVS Low-Latency StreamingのChannelリソースを作成します。IVSのマネジメントコンソール、Low-latency streamingのChannel一覧ページから[Create channel]ボタンで進みます。Channel nameを適切に入力、またChannel configurationはDefault configurationで進めました。

st03

Playback restrictionはデフォルトの無効で進めます。Auto-record to S3（S3への自動録画機能）について、今回は検証のため有効にしました。Enable automatic recordingをチェックして[Create recording configuration]ボタンで現れるダイアログでrecording configurationを作成します。

st04

st05

このRecording configurationを使ってChannelを作成します。

st06

st07

Channelが作成できました。

st08

Stream configurationの項目でStream keyならびにIngests serverの情報を、またPlayback configurationの項目でPlayback URLを確認しておきます。

st09

Streaming Software (OBS Studio)の準備

続いてIVS Channelに映像を打ち上げるStreaming Softwareの準備を行います。今回Streaming SoftwareにはOBS Studioを使用しました。また、もともとストリームを行っている環境（便宜上、本エントリではこちらをBroadcaster Aと称することとします）と、引き継ぎ先としてストリームを行う環境（同じく本エントリ内ではBroadcaster Bとします）を準備します。今回は2台のMacを準備し、それぞれでOBS Studioを起動しました。（少し調べてみたところ、1台のMacでOBS Studioを多重起動することもできるようですが、今回は端末が準備できたこともあり、シンプルに2台を使用するかたちで進めました。）

OBS Studioの映像ソースの準備

OBS Studioを起動後、ストリームする映像について準備します。Broadcaster Aについてはメディアソースを使い、動画ファイルをループ再生させておきます。iPhoneで撮影した井の頭公園の映像ですね。

st10

別端末で起動してるOBS Studio、引き継ぎ側となるBroadcaster Bですね。こちらは映像キャプチャデバイスを使い、USBカメラからの映像を入力としています。

st11

OBS Studioの出力についての設定

続いてAmazon IVS Low-Latency Streaming User GuideのStep 5: Set Up Streaming Software - Streaming with OBS Studio using RTMPSを参考にしながら、OBS Studioの出力についての設定を行います。

OBS Studioの[設定]ボタンから出力の項目を開きます。出力モードで詳細を選択、エンコーダ設定の キーフレーム間隔 を2 sに設定します。

st12

その他の項目はデフォルト設定で進めています。映像の項目についても、以下のデフォルト設定で検証を行いました。

st13

OBS Studioの配信先の設定

配信先の設定です。配信の項目を開きます。サービスで カスタム…を選択し、サーバー の項目には先ほどIVSマネジメントコンソールで確認したIngest serverの値を入力します。

ストリームキー の項目には、こちらも先ほどIVSマネジメントコンソールで確認したStream keyの値をいれるのですが、末尾に?priority=Nという形式でStream Tokeoverの優先順位を指定します。以下の形式ですね。

<streamkey>?priority=N

<streamkey>はマネジメントコンソールから確認できるStream keyの値です。クエリ文字列priorityに対する値となるNについては、1から2,147,483,647までの正の値で指定する必要があります。ストリームの引き継ぎをする際にこのpriorityの値をチェックし、進行中のストリームよりも 大きい値 の場合にStream Takeoverが成功するとのことです。

今回は以下のように設定を行いました。

Broadcaster A
- <streamkey>?priority=10
Broadcaster B
- <streamkey>?priority=100

以下は<streamkey>?priority=10と設定した、Broadcaster Aの設定画面のスクリーンショットです。

st14

視聴ページの準備

IVS Channelからの映像を再生する視聴ページを準備します。AWSマネジメントコンソールでも視聴確認はできますが、今回は以下のようなAmazon IVS Player SDKを利用したHTMLページを作成し、HTTPSでアクセス可能な場所に配置しました。（今回はCloudFront + EC2な環境に配置していますが、この詳細については省略します。）

変数PLAYBACK_URLには、先ほどChannelリソース作成の際にAWSマネジメントコンソールで確認したPlayback URLを指定します。

ivs-stream-takeover-channel.html

<html>
  <head>
    <title>ivs-stream-takeover-channel</title>
    <style>
      video {
          height: 100%;
          width: 100%;
          left: 0;
          top: 0;
          position: fixed;
      }
    </style>
  </head>
  <body>
    <video id="video-player" playsinline controls></video>
    <script src="https://player.live-video.net/1.33.0/amazon-ivs-player.min.js"></script>
    <script>
      var PLAYBACK_URL = "https://xxxx.ap-northeast-1.playback.live-video.net/api/video/v1/ap-northeast-1.123456789012.channel.xxxxxxxx.m3u8"
      if (IVSPlayer.isPlayerSupported) {
          const player = IVSPlayer.create();
          player.attachHTMLVideoElement(document.getElementById('video-player'));
          player.load(PLAYBACK_URL);
          player.play();
      }
    </script>
  </body>
</html>

Stream Takeoverの確認

IVSのリソースならびにStreaming Software、そして視聴ページそれぞれの準備ができました。それではいよいよ、本エントリの主役であるStream Takeoverについて確認していきます。

まずはBroadcaster Aで[配信開始]ボタンを押下、ストリームを開始します。映像視聴ページではBroadcaster Aからストリームされる井の頭公園の映像が流れますね。

st22

st23

ここで、Broadcaster Aから映像を配信したまま、Broadcaster Bの配信もスタートしてみます。ここからは画面収録した動画でご確認ください。

https://youtu.be/RrVhHwDGz7c

左側が映像視聴ページ、右側がBroadcaster Bに該当するOBS Studioです。動画の00:20のタイミング、OBS Studioで入力としている映像の内の時計が17:44:00になったタイミングでBroadcaster Bの[配信開始]を押下しました。IVSからの映像を再生している左側のWebブラウザでは、00:25のタイミングで一瞬バッファリング状態になり、すぐに再生が再開され、00:28にBoadcaster Bからの映像に切り替わりました。

一瞬のバッファリングは入りましたが、再生側としては特にページのリロードなどをすることなく、映像がBroadcaster Aからストリームされているものから、Broadcaster Bからストリームされているものに引き継がれました。

IVSのマネジメントコンソールの表示についても確認してみましょう。Stream sessionについては1つだけで、Boadcaster Bからのストリームに引き継がれても別のStreeam sessionになることはありませんでした。

st15

Stream sessionの詳細ページに進み、Eventsの項目を確認してみましょう。2枚目のスクリーンショットのほう、47 seconds agoに Stream Takeover の記録がありますね。（ちなみに、この何秒前の表記はリアルタイムで数字がカウントされています。スクリーンショットを取った数秒のタイムラグで少し表記がズレているのはそのためです。）

st16

st18

なお、そのあと数回にわたり Stream Takeover Failuer が記録されています。これはBroadcaster Bからのストリームに対して発生しているのではなくBroadcaster Aからのストリームに対し発生しています。実際にBroadcaster AとなっているOBS Studioを確認してみましょう。配信が切断され、再試行を試みている状態となります。

st19

Broadcaster Aで再試行を試みてはいるのですが、優先度の設定からBroadcaster BからBroadcaster AへのStream Takeoverは発生せず、Broadcaster Bの映像が配信されている、という状況となるわけですね。

なお、このStream takeoverとStream takeover failuerの記録については、同ページ内のStream metricsの項目でも表記されています。（Stream Takeoverと直接関係しませんが、OBS Studioが切断後の再接続をとても良い感じに実施していることも確認できますね。）

st20

S3への自動録画についても確認してみましょう。IVS Low-Latency Streamingの自動録画機能では、指定したS3バケットへ以下のプレフィックスで映像が保存されます。

/ivs/v1/${AWS_ACCOUNT_ID}/${CHANNEL_ID}/${YEAR}/${MONTH}/${DAY}/${HOURS}/${MINUTES}/${RECORDING_ID}

S3のマネジメントコンソールから保存先に指定したS3バケットを辿っていきます。/ivs/v1/${AWS_ACCOUNT_ID}/${CHANNEL_ID}/${YEAR}/${MONTH}/${DAY}/${HOURS}までたどり、${MINUTES}フォルダ一覧を表示したのが以下のスクリーンショットです。複数のフォルダは作成されていませんね。Broadcasterが変わっても自動録画が分割されず、1つにまとまっていることが確認できました。

st24

まとめ

Amazon IVS Low-Latancy Streamingの新機能、Stream Takeoverについて確認してみました。より高い優先度priorityを指定したStreaming Softwareからのストリームにシームレスに引き継ぎが可能です。視聴者への映像には一瞬バッファリングが入るもののの、動画再生ページをリロードすると行ったことは不要です。Stream sessionやS3への自動録画も中断することはありません。

長時間ストリーミングを行っているような環境下で各種機器のメンテンスなどが発生、どうしてもStreaming Softwareを停止せざるを得ないようなとき、このStream Takeoverを使えばStream sessionを中断せずにストリーミングを続けることができますね。また、例えばスマートフォン（IVS Broadcast SDK）を使ったストリームで異なる場所からの映像をシームレスにつなげていく、ということもできるかもしれません。なおUser Guideに記載がありますが、古いストリームと新しいストリームとでコーデックや解像度などを揃えておく必要があること、またStream takeoverの最大回数がストリームあたり100のQuotaになっていることに注意しておきましょう。後者はService Quotasで調整可能とのことです。

本機能を確認しながら、筆者は以前のIVS Low-Latency Streamingのアップデート「Merge fragmented streams」を思い出しました。Streaming SoftwareからIVS Channelへのストリームが停止した際、一定期間内に再開すればS3への自動録画がマージされて1つになる機能ですね。こちらはストリームの停止の際、Stream sessionとしては新しいsessionとなっていました。